machine.channel Fix hanging on read_until_prompt. #119
Conversation
On some devices, logs may be printed just after the prompt. In such case prompt lands in the middle of a buffer, not at the end. This change is to avoid infinite hanging in such cases. Signed-off-by: jacekk <[email protected]>
|
Hi, tbot intentionally only accepts a prompt at the very end of the input stream. If there are messages on the console that get printed in-between synchronous command execution, tbot cannot work reliably at all. The solution must always be to avoid the clutter. Any other way, and you will see random testcase failures that can't be controlled. Maybe you can share a few more details about the situation where you are facing this problem? Usually, there are workaround to console clutter from the various sources. |
|
Hi, On one hand, I understand your chain of thoughts. On the other, to have robust automation, it's better to be prepared for the worst case. Practical example is a device that experiences link flapping during the test, so it logs link up/link down events. Sometimes, such event lands at the end of a buffer, just after the prompt. Of course, with some effort, these events can be silenced, but then we lose a bit of observability. Please take a look a few lines under the proposed patch. In case of BoundedPattern prompt, tbot uses search, instead of endswith equivalant. That is actually what convinced me that endswith->find may be a desired solution for tbot community. BR, |
On some devices, logs may be printed just after the prompt. In such case prompt lands in the middle of a buffer, not at the end. This change is to avoid infinite hanging in such cases.